8.2.2 System Architecture



		8.2.2 System Architecture (SysArc)

Systemarchitektur

Contents
Introduction
Document Index
Document Structure
Product Flow
Links to the V-Model Mailinglist

Contents		Introduction Document Index Document Structure Product Flow Links to the V-Model Mailinglist

Introduction

The System Architecture describes the static system structure as a network structure with the elements of the generic product structure. The description includes the elements of the product structure up to the SW Units/HW Units. The architectures of the SW Units and the HW Units can be found in the corresponding architecture documents.

The product System Architecture includes possible solution proposals, results from feasibility studies, the IT security concept, the IT security model, and the allocation between User Requirements and the elements of the System Architecture.

Document Index

1. General Information
2. System Structure
2.1. Representation of the Technical System Architecture
2.1.1. Technical System Structure
2.1.2. Identification of Interfaces
2.1.3. Requirements Allocation
2.2. Explanation of the Cooperation of Technical Elements
3. Realization
3.1. Solution Proposals
3.2. Feasibility Studies
4. IT Security Concept
5. IT Security Model

Document Structure

1. General Information

See schema 1. General Information.

2. System Structure

2. 1. Representation of the Technical System Architecture

2. 1. 1. Technical System Structure

The System is represented as a network of elements of the technical architecture. In this connection, the possibilities of the generic product structure are applied, if possible, to combine SW Units/HW Units into suitable Segments, and the Segments into Systems. The architectural parts are uniquely identified and marked by means of the information from the CM Plan. The element list of the architecture must be complete and consistent.

Those parts of the System that are to be realized with off-the-shelf products or in which off-the-shelf products are to be used have to be specified.

During the System Architecture design it is necessary to observe that, normally, the technical structure of an IT system and the organization at the user have an impact on each other. The user organization has an important impact on solution approaches, and has to be consulted, on the one hand, with regard to considerations about the System Architecture. In IT systems with a client-server architecture, on the other hand, capacities for technical system and user support may have to be planned at the actual site, in the user organization. These considerations should also include the distribution of new system versions and variants during system utilization, and should be regulated in an organizational manner. In this connection, both technical and economical aspects have to be taken into consideration.

2. 1. 2. Identification of Interfaces

The identification of the interfaces results from the architecture; the interfaces are uniquely identified in a table, together with the name of the corresponding partner. The interfaces are defined within the scope of the technical design. This is where the system-internal and system-external interfaces are identified. Technical interfaces are identified that, in general, do not uniquely match with user-level interfaces.

2. 1. 3. Requirements Allocation

The relationships between the elements of the System Architecture (Segments and SW Units/HW Units) and the requirements (interface requirements, functional requirements, quality requirements, etc.) as well as the marginal conditions contained in the product User Requirements are set up in the form of a table. This is to prove that all requirements and marginal conditions are addressed by the elements of the System Architecture.

The table includes

the allocation of the requirements to the elements of the technical architecture, and
information about the technical operation.

The following items have to be observed:

Every requirement must be allocated to at least one element of the technical architecture, ideally exactly to one architecture element.

Each requirement is allocated to the lowest element in the refinement levels which makes it possible to meet the requirement completely. Normally, the total of the requirements has to be allocated to various refinement levels.

Provided that a requirement is of general importance to elements, it must be considered within the scope of the allocation which individual architecture elements this requirement really has to fulfill.

The allocation must be realized in such a manner that it will be possible to prove the fulfillment of the requirement by checking the corresponding architecture element.

When allocating User Requirements to elements, it is possible to make references to the specifications with regard to technical operation. While doing so, it is possible to refer to technical architecture.

In object-oriented development, the following must be observed: The functional User Requirements are described by means of "use cases". These User Requirements are finally realized in class hierarchies and the corresponding cooperation. In object-oriented development, the allocation of the User Requirements can therefore be realized by an allocation of "use cases" to class (hierarchy) groups, whereby these requirements will be met by the cooperation of these "use cases" and class groups.

2. 2. Explanation of the Cooperation of Technical Elements

This contains an illustration of the technical sequences of operation, as they result from the technical architectural decisions. This is only realized on the basis of the technical architecture. (In no case does this concern a change or overlap with regard to the contents with the user-level business processes.)

In addition, the inter-computer process communication that is to be refined within the scope of the Software Architecture at some later time must also be described here, if necessary.

Examples: Technical operation of the users' communication via a client-server network on the basis of a Novell network; technical solution for the access of selected users to the Internet; technical support of the signature tracing via e-mail.

3. Realization

3. 1. Solution Proposals

Solution proposals may refer to freely selected sections of the architecture. They are neither to be limited to a level of the generic product structure nor to individual elements of a System.

Solution outlines for the structure of the System or system parts describe the architecture idea and the decomposition of the System or system part. The User Requirements are in every case the basis for the system outlines.

When generating solution proposals, the possible use of off-the-shelf products must be taken into consideration.

3. 2. Feasibility Studies

The solution proposals are evaluated in such a manner that the advantages and disadvantages with regard to feasibility can be illustrated.

The results of the market analysis with regard to the availability of appropriate Off-the-shelf-products have to be documented.

The following aspects may be considered within the scope of the feasibility study:

development requirements (e. g. use of special programming languages)
consideration of special requirements for critical system parts (in particular interlacement with other components)
impacts of special equipment of target computer
impacts of using off-the-shelf products (reference to requirements controlling)
error handling concept
synchronization and communication mechanisms
necessary special developments
benchmark results

The selection decision for the solution proposal must be documented in a comprehensible way.

4. IT Security Concept

This chapter describes the IT security strategy and, on this basis, justifies the system measures and the measures in the system environment which, by means of their interaction, cover the IT security requirements.

The tasks of the measures and the responsibility during realization must be documented. The efficiency of the overall measures, their compatibility with regulations and rules, the cost/benefit ratio and the residual risk have to be justified.

5. IT Security Model

In case an IT security model is required it is necessary to prove that the IT security requirements are consistent and that the objectives of the IT security concept will be adhered to by means of the modeled IT security functions and its external interfaces.

Product Flow

Chapter		Activity	From		to		Methods	Tool Req.	Ext. Norms
No.	Title	Activity	Activity	State	Activity	State	Methods	Tool Req.	Ext. Norms
2.1.1	Technical System Structure	SD2.1	-	-	SD2.2 SD2.3 SD2.4	being proc.	COM CRC PRODIAG SSM	SSD22 SSD23 SSD25
2.1.2	Identification of Interfaces	SD2.1	-	-	SD2.2 SD2.3 SD2.4	being proc.
2.1.3	Requirements Allocation	SD2.4	-	-	SD1 SD2.5 SD2.6 SD3 SD4-SW PM4 PM5	submitted	ER	SSD01 SSD09
2.2	Explanation of the Cooperation of Technical Elements	SD2.1	-	-	SD2.2 SD2.3 SD2.4	being proc.	IAM	SSD28
3.1	Solution Proposals	SD2.1	-	-	SD2.2 SD2.3 SD2.4	being proc.	COM CRC FCTD SSM	SSD22 SSD23
3.2	Feasibility Studies	SD2.3	-	-	SD2.1 PM5	being proc.	BA SIMU	SSD18 SSD19
4	IT Security Concept	SD2.1	-	-	SD2.2 SD2.3 SD2.4	being proc.
4	IT Security Concept	SD2.2	-	-	SD2.1	being proc.
5	IT Security Model	SD2.1	-	-	SD2.2 SD2.3 SD2.4	being proc.
Existing		SD2.1	SD2.2	being proc.	-	-
Existing		SD2.1	SD2.3	being proc.	-	-
Existing		SD2.1	SD2.4	being proc.	-	-

Links to the V-Model Mailinglist

Mail 0653 - QS-Plan: Fragen zu Festlegung der Kritikalit�t, Vererbung, Infizierung und zugh�rigen Dokumenten (653)
Mail 0594 - Unterst�tzung der Betriebseinf�hrung (594)
Mail 0524 - Mehrere Fragen zum V-Modell (524)
Mail 0197 - IT-Sicherheitskonzept (197)
Mail 0156 - Re: SE 2, Systemarchitektur (156)
Mail 0148 - SE 2, Systemarchitektur (149)

This page online • GDPA Online • Last Updated 06.Mar.2003 by C. Freericks